The Manager's Path

🚀 The Book in 3 Sentences

This book is for technical people who aspire to become great leaders. Camille goes through her experiences and discusses what is required of you at each step of the ladder to management. She discusses how to act as a technical manager, how to interact with people and direct reports and identify issues.

🎨 Impressions

I liked it, it was well-written. I think this is a good book to reference from time to time when you are on the tech-lead, manager path.

✍️ My Top Quotes

• If you are interested in improving on purely the people management side of leadership, books like First, Break All the Rules

• When you are interested in being promoted, it’s very important to ask your manager for specific areas to focus on in order to get that promotion. Managers usually cannot guarantee promotions, but good managers know what the system is looking for and can help you build those achievements and skills.

• The very first thing you need to learn is how to work. Maybe you know this already, but when I was first out of college, I didn’t really know how to do the job at all. Because the day-to-day work of tech is very different from school, there are probably a bunch of things you will learn about the process of being a working engineer.

• Also advise you to find the best managers and mentors you can, and watch them work. Try to find people to work for who push you to succeed but also reward you for success,

• Some offices, whether in a mentoring relationship or outside of one, you’ll encounter an “alpha geek.” The alpha geek is driven to be the best engineer on the team, to always have the right answer, and to be the person who solves all the hard problems. The alpha geek values intelligence and technical skill above all other traits, and believes these attributes should determine who gets to make decisions. The alpha geek usually can’t deal with dissent, and is easily threatened by those she perceives as trying to steal her spotlight or who might upstage her.

• The alpha geek is usually an excellent, effective engineer who goes into management either because she was pushed into it or because she believes that the smartest person on the team should be the manager.

• Mentoring, when done well, starts to shape the skills every future leader needs. Even for those who won’t go on to make management their career, there are clear benefits to taking some time to mentor and learn from the experience, because mentoring forces you to hone your communication skills.

• Senior engineers can develop bad habits, and one of the worst is the tendency to lecture and debate with anyone who does not understand them or who disagrees with what they are saying

• Tech lead is not the job for the person who wants the freedom to focus deeply on the details of her own code.

• My job as tech lead was to continue to write code, but with the added responsibilities of representing the group to management, vetting our plans for feature delivery, and dealing with a lot of the details of the project management process.

• A leader, responsible for a (software) development team, who spends at least 30 percent of their time writing code with the team.

• Systems architect and business analyst In the systems architect and business analyst roles, you identify the critical systems that need to change and the critical features that need to be built in order to deliver upcoming projects.

• The Stone of Triumph is a metaphor for achieving recognition only to discover that recognition comes with a heavy price.

• Doesn’t agile software development get rid of the need for project management? No. Agile software development is a great way to think about work because it forces you to focus on breaking tasks down into smaller chunks, planning those smaller chunks out, and delivering value incrementally instead of all at once.

• The process czar believes that there is one true process that, if implemented correctly and followed as designed, will solve all of the team’s biggest problems. Process czars may be obsessed with agile, Kanban, scrum, lean, or even waterfall methods.

• Process czars are often found in QA, helpdesk, or product management groups. They’re also common in consulting agencies and other places where measurement of specific work progress is highly rewarded.

• Process czars struggle when they fail to realize that most people are not as good at following processes as they are. They tend to blame all problems on a failure to follow the best process, instead of acknowledging the need for flexibility and the inevitability of unexpected changes.

• New engineering managers think of the job as a promotion, giving them seniority on engineering tasks and questions. This is a great approach for ensuring they remain junior managers, and unsuccessful leaders at that. It’s hard to accept that “new manager” is an entry-level job with no seniority on any front, but that’s the best mindset with which to start leading.

• One strategy is to ask a series of questions that are intended to help you get to know the aspects of the person that impact your ability to manage him well. These questions might include: How do you like to be praised, in public or in private? Some people really hate to be praised in public. You want to know this. What is your preferred method of communication for serious feedback? Do you prefer to get such feedback in writing so you have time to digest it, or are you comfortable with less formal verbal feedback? Why did you decide to work here? What are you excited about? How do I know when you’re in a bad mood or annoyed? Are there things that always put you in a bad mood that I should be aware of? Maybe a direct report fasts for religious reasons, which sometimes makes him cranky. Maybe he always gets stressed out while on-call. Maybe he hates reviews season. Are there any manager behaviors that you know you hate? If you asked me this question, my answer would be: skipping or rescheduling 1-1s, neglecting to give me feedback, and avoiding difficult conversations. Do you have any clear career goals that I should know about so I can help you achieve them? Any surprises since you’ve joined, good or bad, that I should know about? Things like: Where are my stock options? You promised me a relocation bonus and I haven’t gotten it yet. Why are we using SVN and not Git? I didn’t expect to be so productive already!

• For more ideas, see Lara Hogan’s excellent blog post on the topic.

• My goal in a 1-1 is first to listen to anything my direct reports want to discuss. I want the meeting to be driven by them, and I want to give them space to bring up whatever they feel is important. I view a 1-1 session as much as a creative discussion as a planning meeting.

• Autonomy, the ability to have control over some part of your work, is an important element of motivation. This is why micromanagers find it so difficult to retain great teams.

• As situations arise, use coaching to ask people what they might have done differently. When things are going well, praise them, but also make suggestions as to what could be even better in the future.

• The 360 model is a performance review that includes feedback from, in addition to a person’s manager, his teammates, anyone who reports to him, and coworkers he regularly interacts with, as well as a self-review.

• Furthermore, if you truly wish to command the respect of an engineering team, they must see you as technically credible. Without technical credibility you face an uphill battle, and even though you may be able to get into a position of leadership in one company, your options will be limited.

• My advice is to dedicate 20% of your time in every planning session to system sustainability work (“sustainability” instead of the more common “technical debt”).

• The challenge of the brilliant jerk is that she’s probably been rewarded for a very long time for her brilliance, and she clings to it like a life raft.

• These days, most places claim that they don’t tolerate brilliant jerks, but I personally don’t believe that is true. It’s incredibly hard for a manager to justify getting rid of someone who produces great work, even though she’s a drain on everyone around her — especially if this person is only irregularly a jerk.

• You have 10 productive engineering weeks per engineer per quarter

• Budget 20% of time for generic sustaining engineering work across the board

• By “generic sustaining engineering work,” I mean testing, debugging, cleaning up legacy code, migrating language or platform versions, and doing other work that has to happen. If you make this a habit, you can use it to tackle some of the midsize legacy code every quarter and get decent improvements.

• As you approach deadlines, it is your job to say no

• Use the doubling rule for quick estimates, but push for planning time to estimate longer tasks

• The popular doubling rule of software estimation is, “Whenever asked for an estimate, take your guess and double it.” This rule is appropriate and good to use when you’re asked for an off-the-cuff guess.

• Be selective about what you bring to the team to estimate

• Part of the reason that I stress your role in this estimation and planning process is that it’s distracting and stressful for engineers to have a manager who’s constantly asking them for random project estimates.

• You’ll start to recognize the early warning signs of projects that are going poorly, people who are getting ready to quit, and teams that are underperforming.

• You think carefully about dropping out of meetings, and part of the reason is that those meetings are where you learn what healthy and unhealthy dynamics look like.

• The person who is usually chatty, happy, and engaged suddenly starts leaving early, coming in late, taking breaks to leave during the workday, staying quiet in meetings, and not hanging out on chat.

• The tech lead claims that everything is going well, but skips your 1-1s frequently and rarely provides detail in his status updates.

• The team has absolutely no energy at all in their meetings. In fact, the meetings feel like a total slog,

• The team’s project list seems to change every week, depending on the customers’ whims that day.

• I love Larry Wall’s idea that “laziness, impatience, and hubris” are virtues of engineers,

• Whether you have experienced managers or first-timers reporting to you, there is one universal goal for these relationships: they should make your life easier. Your managers should allow you to spend more time on the bigger picture, and less time on the details of any one team.

• In his book High Output Management,1 Andy Grove talks about cultural values as one of the ways that people make decisions inside of highly complex, uncertain, or ambiguous circumstances where they value the group interest above their own.

• His observation is that most new hires act in self-interest until they get to know their colleagues, and then they move into group interest. So, if you start them in a highly complex or uncertain job, they tend to fail unless they quickly settle into the cultural norms and use cultural values to align their decision making.

• Dedicate 20% of your team’s schedule to “sustaining engineering.” This means allowing time for refactoring, fixing outstanding bugs, improving engineering processes, doing minor cleanup, and providing ongoing support.

• Understand how important various engineering projects really are. Product and business projects usually have some kind of value proposition to justify them.

• Assessing Your Own Experience How often do you talk to your skip-level reports? Do you meet with them one on one, or as groups? How do you proactively reach out to your teams? How much time do you spend seeking out information, instead of passively handling the information that comes to you? When was the last time you sat in on a team meeting? Without looking at your existing documentation, write down your view of the job description for the engineering managers who report to you. What are they responsible for? How do you evaluate them? What areas are most important for success, in your opinion? Now, look at the job description your company uses. Are there differences in what you wrote compared to that description, or do they match well? Given that description, what things are you potentially overlooking in evaluating them? Finally, do a quick mental review of their current performance. What areas need coaching and development? Make time to cover this in your next 1-1. If you manage an area that is outside of your technical comfort zone, how often do you check in on that area to make sure things are going well? Have you taken some time to learn from the manager of that area a little bit about what it takes to succeed in that role? What new things have you learned in the past three months that help you understand that team better? If you have one team that is clearly operating more smoothly than others, what are the differences you notice in their processes? Their interactions? Is their manager doing things differently than other managers? How does the team interact with that manager, and how does that manager interact with you? What is your interview process for managers? Do you spend time talking about their personal values and their management philosophy? Do you have the team interview their potential manager, or do you keep them out of the process? Do you spend time getting references for candidates? What are your organization’s goals this quarter? This year? How are you merging product goals (if any) with the technical goals? Does your organization have a mandate that is well understood by the teams?

• It took me a long time to realize that my job wasn’t to be the smartest person in the room. It wasn’t to be “right.” Rather, my role was to help the team make the best possible decisions and help them implement them in a sustainable and efficient way.

• Many problems will get raised to you and then resolved on their own, so you may decide you need a degree of sustained struggle from your team before it’s time to step in. I’m not recommending that you adopt the “three-times rule” as a policy, but it does tend to happen, whether you plan for it or not.

• Overall structure. When I talk about senior leadership, I emphasize strategy as a critical element.

• How do you know if you’re creating a culture of fear? It can come from placing a high value on being correct and following the rules, and having a strong affinity for hierarchy-based leadership. I also believe that coming from places where conflict was openly tolerated, if not actively encouraged, made me even more likely to create this culture.

• This role, played by the senior leader of a functional area (the CTO plays it for technology, the CFO plays it for finance, etc.), sets the baseline of what excellence looks like in this function. I call it “True North.”

• True North represents the core principles that a person in a functional role must keep in mind as he does his job. For a product leader, True North includes thinking of the users and their needs first and foremost, measuring and experimenting as much as possible, and pushing back on projects that don’t address the stated goals of a team.

• Leadership and Self-Deception: Getting Out of the Box

• Daring Greatly: How the Courage to Be Vulnerable Transforms the Way We Live, Love, Parent, and Lead

• What Got You Here Won’t Get You There: How Successful People Become Even More Successful

• When talking about structure with skeptics, I try to reframe the discussion. Instead of talking about structure, I talk about learning. Instead of talking about process, I talk about transparency. We don’t set up systems because structure and process have inherent value.

• One of the greatest writings about organizational politics is a piece called “The Tyranny of Structurelessness” by Jo Freeman. While the article is about early feminist/anarchist collectives, Freeman’s insights apply equally well to startup culture.

• Pretending to lack structure tends to create hidden power structures resulting from the nature of human communication and the challenges of trying to scale that communication.

• Unstructured group can, in fact, work: It is task oriented. Its function is very narrow and very specific, like putting on a conference or putting out a newspaper. It is the task that basically structures the group. The task determines what needs to be done and when it needs to be done. It provides a guide by which people can judge their actions and make plans for future activity. It is relatively small and homogeneous. Homogeneity is necessary to insure that participants have a “common language” for interaction. People from widely different backgrounds may provide richness to a consciousness-raising group where each can learn from the others’ experience, but too great a diversity among members of a task-oriented group means only that they continually misunderstand each other. Such diverse people interpret words and actions differently. They have different expectations about each other’s behavior and judge the results according to different criteria. If everyone knows everyone else well enough to understand the nuances, they can be accommodated. Usually, they only lead to confusion and endless hours spent straightening out conflicts no one ever thought would arise. There is a high degree of communication. Information must be passed on to everyone, opinions checked, work divided up, and participation assured in the relevant decisions. This is only possible if the group is small and people practically live together for the most crucial phases of the task. Needless to say, the number of interactions necessary to involve everybody increases geometrically with the number of participants. This inevitably limits group participants to about five, or excludes some from some of the decisions. Successful groups can be as large as 10 or 15, but only when they are in fact composed of several smaller subgroups which perform specific parts of the task, and whose members overlap with each other so that knowledge of what the different subgroups are doing can be passed around easily.

• There is a low degree of skill specialization. Not everyone has to be able to do everything, but everything must be able to be done by more than one person. Thus no one is indispensable. To a certain extent, people become interchangeable parts.

• Earliest startup as like driving a race car. You’re close to the ground, and you feel every move you make. You have control, you can turn quickly, you feel like things are moving fast. Of course, you’re also at risk of crashing at any moment, but you only take yourself down if you do. As you grow, you graduate to a commercial flight. You’re farther from the ground, and more people’s lives depend on you, so you need to consider your movements more carefully, but you still feel in control and can turn the plane relatively quickly. Finally, you graduate to a spaceship, where you can’t make quick moves and the course is set long in advance, but you’re capable of going very far and taking tons of people along for the ride.

• A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system. Your company started as a very simple system that contained a few people, and as more and more people and rules and infrastructure were added, it evolved into a complex system.

• A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

• My advice to leaders is simple: when failures occur, examine all aspects of reality that are contributing to those failures. The patterns you see are opportunities to evolve your structure, either by creating more or different structure or removing it.

• As humans, we tend to blame failure on bad luck until it’s impossible to ignore our own contributions to that failure.

• “Organizations which design systems…are constrained to produce designs which are copies of the communication structures of these organizations.”

• When we put cross-functional teams together, we are acknowledging that the most important communication — the communication that we need to favor above all else — is that which leads to effective product development and iteration.

• Think of process as risk management. As your teams and systems grow, it’s almost impossible for any one person to keep the systems in her head. Because we have a bunch of people coordinating work, we evolve processes around that work coordination in order to make risks obvious.

• One way to think about engineering processes is that they serve as a proxy for how hard or rare it needs to be for something to happen.

• Be clear about code review expectations. For the most part, code reviews don’t catch bugs; tests catch bugs.

• Use a linter for style issues. Engineers can waste absurd amounts of time on questions of style, specifically formatting.

• Keep an eye on the review backlog. Some companies implement a limit on how many outstanding review requests a person can have assigned to him, and they block that person from requesting review when he has too many outstanding requests.